MMD:Polygon Model Data
Revertion The Polygon Model Data (PMD) file format is the file format used to store 3D model information for the models used in the MikuMikuDance (Polygon Movie Maker) animation program. As with any 3D modeling format, this is an extremely detailed file format which has no known documentation other than what many people around the Internet have reverse-engineered. The format is not based on any other known file formats, and so far is completely proprietary to MikuMikuDance. Article originally written by alcexhim. I am currently working with him, and I edited this to make sense from what I have learned from making the new AniMiku rendering engine. ''-Re:VB-P'' In the left column, I have included the byte length of the entry, and the variable type that is used in native code (C or C++). In the right column, I have included either what the value of the entry should be, or what it represents if it is user-modifyable. File header File starts out with simple three char tag followed by a file version. Model header This section stores basic user-generated information about the model that follows the file header. This is only the Japanese model information. The English model information is stored in another section. Vertex information This section stores information about the vertices in the model. It starts out with a byte4 (unsigned long in C++) describing the number of vertices in the model. The following setup will occur once for each vertex. Index information This section describes the indices of the model. The section starts out with a byte4 (unsigned long in C++) describing how many indices are in the model (MUST be a multiple of 3). These are used for connecting the vertices together and drawing the triangles that are used to form the 3D object. Here is a quick explanation: The indices are stored in pairs of 3. Each of these 3 indices represents a corner of a triangle, and points to a vertex in the vertex list. In most 3D APIs (like Direct3D or OpenGL) the API handles drawing these for you with draw functions called "Indexed Drawing" functions. With these, the API will automatically look into the list of indices (called an "Index Buffer") and use each group of three to build a triangle using the index into the list of vertices (called "Vertex Buffer") for each corner of the triangle. This eliminates the need for duplicated vertices, thus saving precious processing power and video memory. For each index: Materials information This section stores information about the materials in the model. All RGBA values are on a scale of 0.0-1.0 which is what most 3D APIs use, not 0-255. It starts out with a byte4 (unsigned long in C++) describing the number of materials in the model. Then, for each material in the model: Bones information This section stores information about the bones in the model. It starts out with a byte2 (unsigned short in C++) describing the number of bones in the model. Then, for each bone in the model: Target Bone Information: *If the bone is an IK follow bone (type 4): **This is the bone index of the IK bone that this bone is effected by. *If the bone is a Co-Rotate bone (type 9, more information can be found by searching for MMD bone types) **This is the "co-rotate coefficient", or the value used to calculate the rotation for this bone. Inverse Kinematics information This section stores information about the IK in the model. Inverse Kinematics is a way of animating a group of related bones all at once (such as arms and legs). It is defined as a way to calculate the rotations of a chain of bones so that the end of the chain reaches a point (in this case a type 2 IK bone). It starts out with a byte2 (unsigned short in C++) describing the number of IK chains in the model. Then, for each IK chain in the model: Face Morph information This section stores information about the face morphs in the model. These are used to "morph" parts of the model (mouth, eyelids, etc). These are NOT the same as bones! Note that this section starts with a "base" face that contains ALL the vertices that will be used IN TOTAL for ALL the rest of the morphs in the model. This section starts out with a byte2 (unsigned short in C++) describing the number of face morphs in the model. Then, for each face morph in the model: Face Vertex List This section comes right after the "Face Type" entry for each face morph data block. It contains the list of vertices that are effected by the face. The position entries represent the maximum possible coordinate that the current face morph can move the vertex to. The coordinates in between are calculated with linear interpolation using the weight value (0.0-1.0, obtained from the VMD motion data). Display Name Information This section describes the display names and groups for the model. This section is only used in MMD to group the bones and face morphs in the dopesheet on the left. Faces Indices for the face morphs which should be displayed in the "Facial" section in MMD. This section starts with a byte1 (unsigned char in C++) representing the number of face morphs to display in the "Facial" section of MMD's dopesheet. Then, for each face morph to display: Bone Group Names Names for the bone groups to display in MMD's dopesheet. This section starts with a byte1 (unsigned char in C++) representing the number of bone groups to create in MMD's dopesheet. Then, for each group: Displayed Bones Indices in the list of bones for which bones should be placed within which groups in MMD's dopesheet. This section starts with a byte4 (unsigned long in C++) representing the total number of bones which should be displayed in all groups. Then, for each displayed bone: This is the end of the base model format. After this is the physics information, english model information, and replacement toon texture information. This is the end of the file for models meant for older versions of MMD, but some models do not use this extended format. Some models may include any number of these 3 sections, but not include the others. Do not assume that the model will contain all the following sections if it contains one of them. English Model Information This section describes the english information for the model. It contains the model information in english, face and bone names in english, and bone group names in english. The section starts with a byte1 (unsigned char in C++) representing whether the model has english information in it. It then follows this setup: English Model Information The model information in english English Bone Names The bone names in english. For each bone in the model: English Face Names The face morph names in english. For each face in the model NOT INCLUDING THE BASE FACE: English Bone Group Names The bone group names in english. For each bone group: Toon Texture Information This section describes which toon texture should be changed from the default, and what they should be changed to. By default, the 10 toon textures MMD uses are toon01.bmp, toon02.bmp, toon03.bmp...toon10.bmp. However, models can replace these with their own toon textures. For each of the 10 toons: Rigid Body Information This section describes the rigid bodies in the model, which are used for physics calculation. MMD uses the Bullet Physics Engine, so the PMD models are formatted so that the information here can easily be plugged into Bullet. As such, everything here will be described in terms of the Bullet API. This section starts out with a byte4 (unsigned long in C++) representing the number of rigid bodies in the model. Then, for each rigid body: Rigid body types: *Kinematic: Body moves with the bone only and is not effected by the simulated physics *Simulated: Body effects the bone, not the other way around. Body is calculated using the physics engine *Aligned: Body is effected by the bone and physics engine Physics Constraint Information This section describes the constraints in the model. These are, once again, specific to the Bullet Physics engine. MMD calculates it's physics dynamically when the model is using by using constraints. Certain rigid bodies (Kinematic type rigid bodies) move only with bones, and are not effected by the physics engine in terms of movement. Bullet then uses these constraints between bodies to simulate the physics of other bodies. For an example, think of Miku's hair. Her head is attached to a Kinematic rigid body so that it can move with the motion freely (last time I knew, your head doesn't go flying around when you walk forward). Her hair is attached to multiple simulated rigid bodies, which are ''effected by the physics engine. The constraints are put in place to make sure that when the rigid body on her head moves (say, she is walking forward), her hair stays attached to her body. That way, her hair is able to freely move, but stay attached to the rest of her body. A constraint exists between 2 rigid bodies only. These can also be called Joints (found in the last tab of PMD Editor, the direct translation of the menu is "Joint"), as they are placed in a position (usually the point where the 2 bones or rigid bodies touch) and have rotation and position limits. This section starts out with a byte4 (unsigned long in C++) representing the number of constraints in the model. Then, for each constraint: **'END OF THE FILE**'''